AI 写代码越来越快，测试怎么接得住：从用例生成到测试工作流重构

如果只是从表面看，好像答案很简单：研发用 AI 写代码，测试也用 AI 写测试用例。研发提效，测试也提效。

但实际做下来，我感觉这个问题没有这么简单。

测试用例生成不是一个单独动作，也不应该是一个单独动作。用例不是凭空来的，它必须有依据。依据不清楚，用例生成得再快，也可能只是生成了一批“看起来完整”的内容。真正要解决的问题不是“AI 能不能写用例”，而是：测试范围从哪里来？测试要点怎么确定？代码变更影响怎么识别？哪些内容可以自动化验证，哪些必须人工判断？测试过程中发现的问题，又怎么反过来改进后续的需求分析和代码分析？

所以，我现在更倾向于把这个问题往前看一步：AI Testing 要接住 AI Coding，不能只做单点的用例生成，而要重构测试工作流。

一、用例生成不能是孤立动作

过去我们讲测试用例生成，更多是把需求文档交给测试人员，由测试人员理解需求、拆测试点、写测试用例。现在有了大语言模型以后，很容易想到让 AI 直接完成这一步。

我也尝试过这种方式。把需求说明、功能描述、接口说明输入给模型，让它按照固定模板输出测试用例，包括用例编号、用例标题、前置条件、执行步骤、预期结果等。

这种方式确实能提高一部分效率。尤其是需求比较清楚、功能比较标准的时候，模型生成的用例格式整齐，覆盖面看起来也比较完整。

但问题也很明显。

有些用例只是正常流程的简单展开，发现问题的能力不强；有些预期结果写得比较虚，比如“系统正常返回”“页面展示正确”“提示信息友好”；还有些用例虽然看起来合理，但和真实系统的风险关系不大。特别是涉及上下游接口、权限边界、批量处理、配置变更、公共组件、历史缺陷这些内容时，只靠需求文档生成用例，很容易漏掉真正关键的地方。

这也让我意识到，测试用例生成的前一步应该是测试范围识别。测试范围识别不清楚，后面的测试要点和测试用例就容易偏。

而测试范围本身，不能只来自需求文档。至少应该来自几个方面：

一是需求文档告诉我们，这个功能“应该做什么”；
二是代码变更告诉我们，这次版本“实际改了什么”；
三是源码结构和调用关系告诉我们，改动“可能影响到哪里”；
四是历史缺陷和测试资产告诉我们，类似场景“以前哪里出过问题”；
五是本次测试执行结果告诉我们，哪些问题需要反哺到后续分析中。

如果这些输入没有打通，只做用例生成，本质上还是在一个局部环节提效。短期能减少一点人工编写工作，但很难真正接住 AI Coding 带来的研发节奏变化。

二、第一条路径：从需求出发，用 AI 辅助提高需求质量

虽然我认为用例生成不能只依赖需求文档，但需求仍然是测试工作最重要的输入之一。

在传统测试流程里，需求质量直接影响后面的测试质量。需求写得清楚，测试人员可以更快理解功能边界、业务规则、异常处理和验收标准；需求写得模糊，后面就会出现大量沟通、返工和争议。

所以，第一套工作模式还是要从需求侧出发。

这套模式可以理解为“需求分析智能体”。它的作用不是简单生成测试用例，而是先辅助测试人员分析需求。

比如，在拿到需求文档后，可以让 AI 先做几件事：

一是提炼需求的核心目标。这个功能到底解决什么问题，面向哪些用户，涉及哪些业务流程。

二是识别需求中的关键信息。包括用户角色、输入输出、业务规则、状态流转、权限要求、数据来源、外部接口、异常场景等。

三是检查需求中的模糊点和缺失点。比如规则没有写清楚、异常处理没有说明、接口依赖不明确、权限边界缺失、性能指标没有给出等。

四是初步输出测试范围和测试关注点。包括功能测试点、数据测试点、权限测试点、异常测试点、接口联动测试点、性能关注点、安全关注点等。

五是在测试人员确认后，生成初始测试用例。

这条路径的重点不是让 AI 替测试人员判断，而是让 AI 帮测试人员更快把需求“读薄”、把问题“列明”、把测试范围“摊开”。

我觉得这对需求评审阶段尤其有价值。因为很多问题如果等到测试执行时才发现，成本已经比较高了。如果能在需求阶段就把模糊点、遗漏点、风险点提前暴露出来，后面的测试设计会更稳。

从这个角度看，AI 不是简单提高用例编写效率，而是在帮助测试工作前移。

三、第二条路径：从代码出发，把测试分析放进开发工作流

如果说需求侧分析解决的是“应该测什么”，那么代码侧分析解决的是“实际改了什么”。

AI Coding 带来的一个明显变化是，代码生成和代码修改的频率可能会越来越高。过去一个功能可能经过比较完整的设计、开发和提测过程，现在借助 AI，研发可以更快完成代码实现、缺陷修复和小范围调整。

这种情况下，如果测试仍然等到提测以后再集中分析，很容易被动。

我认为更合适的方式，是在开发工作流里增加测试分析节点。也就是说，代码提交后，不只是做代码扫描、代码评审、流水线构建，还应该同步触发测试影响分析。

这里可以形成第二套工作模式，也就是“代码分析智能体”。

它可以分成两个层次。

第一个层次是变更代码分析。
基于 Git Diff、提交说明、变更文件、变更方法、接口调整、配置变化等信息，分析本次改动可能影响哪些功能、接口、页面、流程和数据。

比如一次提交只改了几个文件，但这几个文件可能涉及公共方法、权限校验、报文组装、数据库字段映射或外部接口调用。如果只是从需求描述看，可能意识不到这些影响；但从代码变更分析，就能发现更真实的风险。

第二个层次是全量代码分析。
有些影响不是单看 Diff 就能看出来的，还需要结合全量源码结构、调用链、接口依赖、数据库访问、配置文件、定时任务、批处理逻辑等一起判断。

比如某个方法被多个业务流程调用，本次只改了一个方法，但实际影响范围可能超过本次需求本身。又比如改动涉及一个公共组件，表面上是小改动，实际上可能影响多个系统功能。

所以，代码分析智能体不能只看变更文件，还要结合源码上下文和代码分析工具，形成更完整的测试影响范围。

这套模式下，AI 可以输出几类内容：

一是本次代码变更摘要，说明改了什么；
二是受影响的接口、页面、方法、配置、数据库表或字段；
三是可能受影响的业务流程；
四是建议重点验证的测试点；
五是需要回归的历史场景；
六是可以自动化验证的接口或规则；
七是需要人工判断的功能或体验类内容。

这一步对高频、小量改造尤其有意义。

因为高频小改如果每次都按完整传统流程走，测试成本会很高；但如果因为改动小就简单放过，又容易把风险积累起来。代码侧分析的价值，就是把每次小改动都转化成相对明确的测试范围，让测试工作跟得上代码变化。

四、第三条路径：把需求侧和代码侧结果融合起来

需求分析和代码分析都重要，但单独看都不完整。

需求文档告诉我们业务上希望实现什么，但它不一定能反映代码真实改动。代码变更告诉我们系统里实际改了什么，但它不一定能完整表达业务意图。

比如，需求里只写了一个页面字段调整，但代码里可能同时改了字段校验、接口报文和数据库映射。
再比如，代码提交里只看到一个方法修改，但这个方法被多个功能复用，实际影响范围比需求范围更大。
又比如，需求和代码都没有特别提示，但历史缺陷中曾经出现过类似问题，这类场景就应该纳入回归。

所以，还需要第三套工作模式：融合执行智能体。

它的作用是把多路输入合到一起，形成最终测试范围。

这些输入包括：

• 需求分析结果；

• 代码变更分析结果；

• 全量源码分析结果；

• 静态扫描或代码质量检查结果；

• 历史缺陷；

• 已有测试用例库；

• 自动化脚本库；

• 生产问题复盘材料；

• 本次测试执行结果。

融合不是简单拼接，而是要做去重、归类、补充和排序。

比如，需求侧和代码侧都识别到了同一个接口，就需要合并为一个测试点；代码侧发现了公共组件影响，就要补充回归范围；历史缺陷中有类似问题，就要提高优先级；已有自动化脚本能覆盖的，就可以标记为自动化执行；需要人工判断内容质量、页面体验或业务合理性的，就要标记为人工验证。

最终输出的不是一堆散乱的用例，而应该是一份结构化的测试范围和测试执行安排。

我理想中的输出大概包括几类：

一是统一测试范围，说明本次要测什么；
二是测试要点清单，按功能、接口、数据、权限、异常、性能、安全等维度归类；
三是测试用例，区分高、中、低优先级；
四是自动化执行清单，明确哪些可以通过接口、UI 或专项脚本自动验证；
五是人工验证清单，明确哪些必须人工确认；
六是专项测试建议，比如性能、安全、兼容性、长文本、并发、稳定性等；
七是测试报告初稿，自动汇总执行结果、失败项、风险项和待确认问题。

这套模式的核心，是把“测试用例生成”升级成“测试范围识别—测试要点生成—用例分流—执行验证—结果反馈”的完整过程。

五、AI Testing 要接住 AI Coding，关键是频率匹配

从效率角度看，AI Testing 要接住 AI Coding，最关键的问题是频率匹配。

AI Coding 提高的不是单次开发效率这么简单，它还会改变研发节奏。代码提交可能更频繁，单次改动可能更小，版本变化可能更快。

如果研发已经进入高频迭代，而测试仍然停留在低频、集中、后置的工作方式，就会越来越被动。

过去的方式更像是：需求完成后，开发实现，提测后测试再集中介入。
但在 AI Coding 的背景下，这种方式可能不够用了。

更合理的方式应该是：研发和测试处在同一套 AI 辅助工作流中。

我设想的流程是：

第一步，研发通过 AI Coding 完成代码生成或代码修改。
第二步，代码提交后自动进入代码分析节点。
第三步，AI 分析本次 Diff、提交说明、源码结构、接口变化、配置变化和调用影响。
第四步，生成初步测试范围和测试要点。
第五步，测试人员审核这些测试要点，并通过与 AI 交互补充遗漏场景。
第六步，AI 根据确认后的测试要点生成测试用例。
第七步，对测试用例进行分流，区分可自动化执行、必须人工验证、需要专项测试的内容。
第八步，生成接口测试、UI 测试或专项测试场景。
第九步，人工确认后执行测试。
第十步，自动汇总结果，生成测试报告。
第十一步，把发现的缺陷、遗漏的场景、误判的结果，反哺给需求分析和代码分析智能体。

这套流程里，测试不再只是等研发提测后的后置环节，而是在代码变化发生时就开始识别测试范围。

这样做对高频、小量改造会比较有帮助。

因为这类改造最尴尬：每次改动都不大，但数量多、频率高。如果每次都完整人工分析，成本太高；如果只简单验证主流程，又容易遗漏问题。通过 AI 辅助工作流，可以把小改动快速转成可执行的测试任务，让测试跟上研发节奏。

六、人的作用不会减少，而是前移

这里有一点需要说清楚：我不认为这套模式意味着测试人员的作用会变小。

恰恰相反，我判断测试人员的作用会更靠前，也更重要。

过去测试人员主要精力花在看需求、写用例、执行用例、提缺陷上。以后如果 AI 能承担一部分整理、生成和执行辅助工作，那么测试人员更应该把精力放在几个关键判断上。

第一，判断测试范围是否准确。
AI 可以根据需求和代码给出建议，但哪些是真影响、哪些是假影响，哪些必须测、哪些可以降级，仍然需要测试人员判断。

第二，判断测试优先级是否合理。
不是所有测试点都同等重要。核心流程、资金相关、权限相关、数据一致性、外部接口、历史问题多发区域，都应该有更高优先级。

第三，判断哪些可以自动化，哪些必须人工。
接口返回、字段校验、状态流转、规则判断等比较适合自动化；但内容质量、业务合理性、用户体验、复杂场景判断，很多时候仍然需要人工确认。

第四，判断测试结论是否成立。
AI 可以帮助分析日志、整理结果、生成报告，但缺陷是否成立、风险是否可接受、是否满足上线条件，这些结论不能完全交给 AI。

第五，持续修正 AI 的分析结果。
如果 AI 漏了测试点，误判了影响范围，生成了低价值用例，测试人员要把这些问题反哺回去。只有这样，这套工作流才会越用越准。

所以，AI Testing 不是让测试人员少思考，而是把测试人员从大量重复整理工作中释放出来，把更多精力放到风险判断、标准制定和质量把关上。

七、后续可以继续探索的方向

围绕这套思路，我觉得后续可以继续从几个方向推进。

第一，建立需求分析智能体。
围绕标准需求文档，做需求质量检查、测试范围识别、测试要点生成和初始用例生成。重点解决需求输入质量不稳定的问题。

第二，建立代码分析智能体。
嵌入开发工作流，基于代码 Diff、全量源码、接口依赖、配置变化、静态扫描结果等，识别代码变更影响范围，输出测试建议。

第三，建立融合执行智能体。
把需求侧、代码侧、历史缺陷、测试资产、自动化脚本等信息合并，形成统一测试范围，并完成测试用例分流、执行安排和报告生成。

第四，建设测试资产库和历史缺陷记忆。
把项目中发现的问题、历史缺陷、生产问题、专项用例、自动化脚本、测试报告沉淀下来，让后续分析不再从零开始。

第五，完善自动化执行能力。
对适合自动化的用例，进一步生成接口测试、UI 测试、专项测试脚本，逐步提高自动执行比例。

第六，建立反馈机制。
把测试执行结果、缺陷原因、遗漏场景、误判情况反馈给前面的需求分析和代码分析环节，让工作流不断修正。

这几件事如果能逐步做起来，AI 在测试里的作用就不只是生成几条用例，而是能够进入测试工作的主流程。

八、结语

现在回头看，我觉得说AI测试无非就是“大模型生成测试用例”这个说法太片面了。

真正值得做的，不是让 AI 替我们多写几条用例，而是考虑重新设计测试工作流，让用例生成建立在需求分析、代码变更分析、源码分析、历史缺陷和测试资产的基础上。

AI Coding 让研发变快了，AI Testing 要接住这种变化，就不能只在提测后补用例，而要进入研发工作流，在代码变化发生时同步完成测试范围识别、测试要点生成、用例分流和执行验证。

对测试人员来说，未来的重点也会发生变化。不是简单比谁写的用例多，而是看谁能更准确地识别风险，更清楚地定义标准，更有效地组织测试资产，更稳定地设计测试工作流。

我现在越来越觉得，AI Testing 的价值不在于替代测试人员，而在于把测试人员的经验、判断和方法，放进一套可以持续运行的工作流里。这样，测试才有可能真正接住 AI Coding 带来的节奏变化。